Is this same to the one we already have?

LLMs are also point problems on this enum.
I think the enum name should be more like MemoryScope rather than just Scope.
And the values should match to the internal and SPIRV values.

I think we can skip this pass when the cooperative capability is not used or cooperative-vector or cooperative-matrix types are not found earlier.

I am not sure if List is a right container for this when you want to maintain the sorted order.
Although the name List sounds like a linked-list but it is more like std::vector.
The cost of inserting in the middle will be higher than you may expected.

🔴 Bug: Unsafe cast<> usage assumes prior validation holds unconditionally

Three call sites in the cooperative metadata collection use cast<IRIntLit> / cast<IRBoolLit> (here, line 483 for getTranspose(), and line 559 for getSaturatingAccumulation()) based on the comment that validateCooperativeOperations guarantees operand literal types. However, cast<> only asserts in debug builds — in release builds a null or wrong-type operand would silently produce a null pointer and immediately dereference it, causing a crash.

The assumption that validation always precedes this pass is fragile: any future IR pass inserted between validateCooperativeOperations and collectCooperativeMetadata could create or modify cooperative instructions without re-validation. The rest of this file (e.g., _getCooperativeMatrixType at lines 309-341) already uses the defensive as<IRIntLit> + null-check pattern consistently.

Example: If a future optimization pass between validation and metadata collection performs constant folding that replaces an IRIntLit with a different IR node type, cast<IRIntLit>(nullptr) returns null in release builds, and ->getValue() dereferences it.

Suggested fix:

auto packingLit = as<IRIntLit>(matMulAdd->getInputInterpretationPackingFactor());
if (!packingLit)
    return;
IRIntegerValue packingFactorValue = packingLit->getValue();

Apply the same pattern to the cast<IRBoolLit> calls for getTranspose() and getSaturatingAccumulation().

🟡 Gap: operator< defined in slang namespace for public API types

These operator< overloads are defined in the slang namespace for structs declared in the public header include/slang.h. While they are only used internally for sorted insertion within this .cpp file, defining them at namespace scope means they participate in ADL for these types. If any other translation unit (or a downstream consumer) defines a different operator< for the same types in namespace slang, it would be an ODR violation.

Suggestion: Move the comparison logic into an anonymous namespace using named comparator structs or lambdas, and pass them explicitly to the _insertSortedUnique/lowerBound calls. This keeps the ordering internal to this file without polluting the slang namespace:

namespace {
struct CooperativeMatrixTypeLess {
    bool operator()(const slang::CooperativeMatrixType& a,
                    const slang::CooperativeMatrixType& b) const { /* ... */ }
};
} // anonymous namespace

🟡 Gap: New public enum SlangScope lacks documentation

This is a new public API enum that maps GPU execution scopes for cooperative operations. Unlike the struct fields and the ICooperativeTypesMetadata interface (which have doc comments), the enum values have no documentation. Users need to understand the mapping to GPU concepts (thread = invocation, wave = subgroup, thread group = workgroup) and how these correspond to Vulkan/HLSL scopes.

Suggestion: Add a brief doc comment and per-value annotations:

/** Cooperative type execution scope.
 * Specifies the scope of threads that cooperate in matrix/vector operations.
 */
typedef SlangUInt32 SlangScopeIntegral;
enum SlangScope : SlangScopeIntegral
{
    SLANG_SCOPE_NONE,         ///< Invalid/unspecified scope
    SLANG_SCOPE_THREAD,       ///< Single invocation
    SLANG_SCOPE_WAVE,         ///< Subgroup/wave scope
    SLANG_SCOPE_THREAD_GROUP, ///< Workgroup/thread group scope
};

🟡 Gap: No test for deduplication or cooperative vector maxSize merging

The implementation has two key invariants that are not directly validated by any test:

1. Sorted unique insertion (_insertSortedUnique): If the same cooperative matrix type appears in multiple IR instructions, the metadata should contain it exactly once. The existing tests implicitly exercise this (types shared across matmul operands), but no test explicitly verifies that duplicate types are deduplicated — if the sorted-insertion logic regresses, the existing tests wouldn't necessarily catch it because they only check expected counts.

2. maxSize merging (_insertOrUpdateCooperativeVectorType): When the same component type appears with different vector sizes (e.g., CoopVec<4, float> and CoopVec<8, float>), the implementation merges them into one entry with maxSize = max(4, 8) = 8. No test validates this merge behavior. Similarly, the usedForTrainingOp OR-merging when a type appears in both training and non-training contexts is only tested with the mixed test — but that test doesn't verify the maxSize is the maximum across both uses.

Suggestion: Add a targeted test that uses the same cooperative matrix type in multiple operations and asserts the type count is exactly 1 (not 2). Add a second test that uses the same vector component type with sizes 4, 8, 16 and asserts maxSize == 16.

🔵 Question: Default .use = SLANG_COOPERATIVE_MATRIX_USE_A for invalid types

All other fields in CooperativeMatrixType default to zero/NONE to indicate "not valid," but .use defaults to SLANG_COOPERATIVE_MATRIX_USE_A (value 0) because the SlangCooperativeMatrixUse enum has no NONE sentinel. This means a default-constructed or partially-initialized struct has a field that looks valid (USE_A) even when the struct is logically invalid (componentType == NONE).

The doc comment says componentType == NONE is the validity check, so this is consistent — but it could confuse callers who inspect .use without first checking componentType. Is this intentional, or would it be worth adding a SLANG_COOPERATIVE_MATRIX_USE_NONE sentinel to the existing enum (recognizing that changes the enum layout)?